[...] > > My question is this: I own /home/dougmc/ircd/ircd, so I can change it > > in any way I want. Is it possible to alter it in such a way that it > > takes this open fd to port 194 and abuses it, perhaps uses it to spoof > > a rlogin or rsh? > > A quick perusal of (4.3BSD) inetd shows that it forks, the child > gets setuid & setgid to the user that ircd is supposed > to run as (dougmc in this case), and exec()d. Doesn't > look too bad, but I just glanced at the code, and I couldn't > say if any other version of UNIX doesn't do something dumb in inetd. I think you misunderstood the question. What he was asking about is replacing ircd with a trojan which would then use the open port to connect as rlogin or similar. Your average BSD rlogind will check the port the connection comes from, so I assume they all do when they come from your trusty vendor, to make sure it is within the range 512 to 1024, or more precisely, the upper half of whatever it believes is the range for priviledged ports to be (there's a kernel variable on Solaris2 for this...I'm curious about what happens when this becomes 0 :-) So straight away, this puts 194 out of the market. What if it were 594 ? Well, that's a bit more interesting, but unfortunately, you can't perform a connect(2) on a socket (such as the one which inetd will pass you if you specify "wait" for a "stream") after the listen(2) call has been made on it. I've tried this with other port numbers, and no go. Now what I don't know, is what happens when listen() and connect() are NOT kernel system calls (such as with Solaris2). They're an interface to ioctl's (I believe) which do the dirty work that listen(2) and friends used to do. Is it then possible to "undo" those ioctl's ? (Nearly all ioctl's are reversible as they clear/set flags or similar). Anyone ?